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Packet-Switched Telephony Call Server 

eeld. 

The present invention relates to telecommunications over packet-switched networks. 
More particularly, the present invention relates to a call server for use on a packet-switched 
5 network. 

BACKGROUND 

Public packet-switched networks have recently supported voice communications. 
"Internet telephony" is one example of packet-switched telephony. In packet-switched 

1 0 telephony, a packet-switched network, such as the Internet, serves as a transportation medium for 
packets carrying voice data. Voice-over-Internet-Protocol (VoIP) is one example of a collection 
of standards and protocols used to support voice communications over packet-switched networks 
such as the Internet Others have been developed as well. A common Internet telephony scheme 
involves a computer or other device mat is capable of connecting to the Internet A gateway 

15 from the Internet to the Public-Switched Telephone Network (PSTN) allows a user of the 
computer to communicate through the Internet and PSTN to a telephone subscriber at a 
telephone connected to the PSTN. Other configurations are also possible. 

Numerous benefits may be realized' through the use of packet-switched telephony. For 
example, calls may be less expensive because of the utilization of a packet-switched network, 

20 such as the Internet, to traverse distances around the world. This is in contrast to conventional 
telephone service, which typically involves tying up telephone circuits to connect calls. Thus, a 
user in one location may communicate with a telephone subscriber at a second location by 
transmitting voice data across the Internet to a gateway that is located near a telephone 
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subscriber's location, in order to avoid paying some or all of the long distance fees that might 
otherwise be associated with making such a call. Another possible advantage of packet-switched 
telephony service is the convenient interfaces and features that may be offered in a packet- 
switched telephony system. For example, volume control a video session, or an address book 

5 application may be implemented. Many Internet Telephony Service Providers (TTSPs) have 
been formed in order to provide these services. Examples of ITSPs include Go2Call.com, 
Net2Phone, DialPad, Maxcall, AccessPower, and others. Each ITSP generally has its own 
calling rate and fee structure and may require a download of client software. 

The download requirements vary by ITSP, but in general they require an application, 

10 such as a Java applet, and telephony gateway protocol software to be downloaded onto the 
device that will be interfacing with the Internet The Java applet contains a dialing application 
can be used by a device equipped with a Java-capable browser, such as Internet Explorer and 
Netscape. 

Several Internet telephony gateway protocols are available, including H.323, Session 
15 Initiation Protocol (SIP), and Media Gateway Control Protocol (MGCP). International 
Telecommunications Union standard H.323 is the current standard for transmitting voice over 
the Internet One of the limitations of using H.323 is its large size. Downloading an H.323 stack 
can take up to ten minutes depending on a user's modem speed. 

It is common for protocol standards to evolve quickly. As the protocol standards change, 
20 the user must typically download an application supporting the new version of the standard, in 
order to be able to complete an Internet call- The user will be delayed in placing their Internet 
call for the time it takes to download the latest version of the telephony gateway protocol. This 
is an inconvenience to the user and a potential lost subscriber to the ITSP. 
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A user may also wish to access the Internet using a handheld device or a cellular phone. 
Memory in these devices is typically more limited than in personal computers. As a result, large 
downloads may cause memory problems, or may even be impossible. As the world becomes 
more mobile, the use of these devices will likely increase, which will likely further the demand 
5 for Internet telephony. 
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rwtff npsraiPTiON OF the drawings 
Various embodiments are described with reference to the following drawings, wherein: 
Figure 1 is a simplified block diagram illustrating an exemplary packet-switched 
telephony system; 

5 Figure 2 is a simplified block diagram illustrating an exemplary packet-switched 

telephony system; 

Figure 3 is a simplified block diagram illustrating an exemplary call client system; 
Figure 4 is a simplified block diagram illustrating an exemplary Packet-switched 
Telephony Server Provider system; 

10 Figure 5 is a simplified block diagram illustrating an exemplary front end; 

Figure 6 is a simplified block diagram illustrating an exemplary call server, 
Figure 7 is a simplified block diagram illustrating an exemplary call director, 
Figure 8 is a simplified block diagram illustrating an exemplary call handler, 
Figure 9 is a simplified block diagram summarizing user device communications with a 

15 call server, 

Figure 10 is a simplified block diagram illustrating an exemplary call logger, 

Figure 11 is a simplified block diagram illustrating an exemplary proxy server, 

Figure 12 is a simplified block diagram illustrating the details of the PTSP, according to 

an exemplary embodiment; 
20 Figure 13 is a simplified block diagram illustrating an exemplary embodiment employing 

two data streams from a user device; 

Figure 14 is a simplified block diagram illustrating an exemplary embodiment employing 

a single data stream from a user device; 
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Figure IS is a simplified message flow diagram illustrating an exemplary call control 
sequence; 

Figure 16 is a simplified block diagram illustrating an exemplary system for allocating 
assets to a particular telephony protocol; 
S Figure 1 7 is a simplified flow diagram illustrating an exemplary method for providing 

packet-switched telephony service; 

Figure 1 8 is a simplified flow diagram illustrating an exemplary method for providing 
packet-switched telephony service; 

Figure 19 is a simplified flow diagram illustrating an exemplary method for providing 
1 0 packet-switched telephony service; and 

Figure 20 is a simplified flow diagram illustrating an exemplary method for providing 
packet-switched telephony service. 
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fn:TftTT f Fn DESCRIPTION 

I. Packet-Switched Telephony 

Figure 1 is a simplified block diagram illustrating an exemplary packet-switched 
telephony system 100. The system 100 includes a computer 102 from which a user wishes to 
5 place a call to a telephone subscriber located at a phone *104. The computer 102 is linked to a 
packet-switched network 106, such as the Internet An Internet Telephony Service Provider 
(TTSP) or other packet-switched telephony service provider may operate a telephony gateway 
108 between the packet-switched network 106 and a Public-Switched Telephone Network 
(PSTN) 110. The PSTN 110 provides service to the phone 104. The packet-switched network 
10 106 includes network equipment that routes the individual voice data packets to a destination 
address identified in the individual packets. 

The computer 102 contains a microphone 1 12 and speakers 1 14a,b. During a call, a user 
located at the computer 102 can speak into the microphone 1 12 to provide a voice signal input to 
the computer 102. A processor in the computer 102 digitizes the user's voice and assembles the 
15 data into packets according to one or more protocols, such as the Internet Protocol (IP) suite. 
These voice data packets are then transmitted across the packet-switched network 106 to the 
gateway 108. The sampling rate of the voice signal is preferably chosen to be high enough to 
cause the digitized voice data to sound like a continuous voice signal to a human ear. The 
gateway 108 converts the voice data packets back into a voice signal for further transmission on 
20 the PSTN 110. The PSTN 110 transmits the voice signals on a dedicated circuit to the phone 
104. A user located at the phone 104 receives the voice signals, which may be heard through a 
speaker associated with the phone 104. Similarly, the user located at the phone 104 can speak 
into a microphone at the phone 104 to cause a voice signal to be transmitted across the PSTN 
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110 to the gateway 108, where the voice signal is converted into voice data packets for 
transmission across the packet-switched network 106 to the computer 102. The processor in the 
computer 102 may convert the voice data packets into a voice signal to be played on the speakers 
114a,b. 

5 Although the gateway 108 is shown as being a single device in Figure 1, an ITSP may 

have several or many gateways similar to the gateway 108. The different gateways would likely 
be located in various locations around the world to take advantage of possible savings in long 
distance fees. Although the PSTN 110 may offer circuit-switched telephone service to local 
phone subscribers as well as to subscribers located at more distant local exchanges, long distance 

10 fees might be incurred for placing calls through the distant local exchanges. Thus, an ITSP will 
preferably route the call to a gateway having a connection to a PSTN that can provide local 
service to the phone number to be called An ITSP gateway may be used to administer such a 
call routing scheme for a particular ITSP. 

1 5 D. Packet-Switched Telephony Server Provider Exemplary System 

Figure 2 is a simplified block diagram illustrating an exemplary packet-switched 
telephony system 200. The system 200 includes a user device 202, a Packet-switched Telephony 
Service Provider (PTSP) 206, a gateway 208, and a target device 212. The user device 202 is 
linked to the PTSP 206 through a packet-switched network 204, such as the Internet The PTSP 

20 206 is linked to the gateway 208. The link between the PTSP 206 and the gateway 208 may be 
through a packet-switched network, such as the Internet, or some other physical and/or wireless 
network. The gateway 208 is linked to the target device 212 through a PSTN 210 and/or some 
other network. 



8 




According to the exemplary system 200, a user located at the user device 202 may initiate 
a call to a target user located at the target device 212 by participating in a call initiation process 
involving the user device 202 and the PTSP 206. For example, the user device 202 may access a 
web-site maintained by the PTSP 206, using a web-browser, such as Microsoft Internet Explorer 

5 or Netscape Navigator. As another example, the user device 202 may execute a calling 
application to contact the PTSP 206 through the packet-switched network 204. The call 
initiation process may include choosing a phone number or address book entry to call, and may 
include specifying other call parameters. The PTSP 206 continues the initiation process by 
transmitting call initiation information to the gateway 208 so that the gateway 208 may attempt 

10 to reach the target device 212 through the public switched telephone network 210. If the call 
initiation process is successful, voice communications may be transmitted back and forth 
between the user device 202 and the target device 212. Voice data transmitted between the user 
device 202 and the PSTP 206 will preferably consist of packets containing voice information, as 
well as any other information desired by the user at the user device 202, or the PSTP 206. Data 

IS transferred between the PSTP 206 and the gateway 208 will also preferably be packetized data. 
Data transferred between the gateway 208 and the target device 212 via the PSTN 210 may 
include circuit-switched data rather than packet-switched data. Alternatively, the PSTN 210 may 
include one or more portions mat are packet-switched and one or more portions that are circuit- 
switched. As a result of the various conversions and/or conveyances that occur at the PSTP 206 

20 and gateway 208 over the packet-switched network 204 and the PSTN 210, the user device 202 
is able to receive voice data transmitted by the target device 212, and vice versa. 
A. User Device 
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The user device 202 is shown as a simple rectangular box in Figure 2 to emphasize the 
variety of different forms the user device 202 might take on from one embodiment to the next. 
For example, the user device 202 might be any one of the following: a personal computer, a 
mobile phone, a wireless handheld device, or a packet-switched telephone. The user device 202 

5 is not limited to any of these devices, and is intended to encompass future communication and 
information technology. Various embodiments of the system 200 will include a user device 202 
having at least a link to the PSTP 206, a telephony client application, and a mechanism for user 
input and output. For example, the user device 202 may be a device that is capable of accessing 
the Internet and that is operable to execute a telephony client, such as a Java virtual machine or 

10 other "thin" client Further details regarding the user device 202 may be found throughout this 
specification. 

Figure 3 is a simplified block diagram illustrating an exemplary embodiment of a call 
client system 300. The system 300 includes a call client 302 and a browser session 304. The 
call client 302 includes a software library 306 and a Java virtual machine 308. The software 
15 library 306 and the Java virtual machine 308 are linked by an interface 310. The call client 302 
and the browser session 304 are linked by an interface 312. Interfaces 310 and 312 may be 
software links. 

The software library 306 may include functionality for coding voice audio input into 
digital signals and for decoding digital signals into voice audio output, such as a Dynamic Link 
20 Library (DLL). Other functions may also be provided. In a preferred embodiment, the software 
library 306 includes a Real-Time Protocol (RTP) stack, ah Application Program Interface (API) 
(such as a Microsoft Windows API), a voice codec (such as a G.71 1 codec module), and a call 
control stack. In one embodiment, a HyperText Transfer Protocol (HTTP) stack is implemented 
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to assist in firewall circumvention. Additionally or alternatively, a port scan module may be 
included to identify potential ports to use to avoid firewall interference. 

The Java virtual machine 308 preferably includes an interface, such as a Graphical User 
Interface (GUI). According to an alternative embodiment, the Java virtual machine 308 also 
S includes a billing system, to assist in keeping track of call time and other potential billing 
parameters. While the Java virtual machine 308 includes "Java" in its description, the Java 
language is merely one implementation, and other languages and module types are also intended 
to be within the scope of the present system. Java, from Sun Microsystems, is merely one 
possibility for implementing the Java virtual machine, and the provided functionality (e.g. GUI) 
10 is more relevant than the particular implementation of the Java virtual m ac hin e. 

The browser session 304 is operable to support a Java virtual session, such as one 
downloaded from the PTSP 206. 

The user device components described above are merely preferred implementations, and 
variations may be made without departing from tile intended scope of the present system. For 
15 example, one or more of the user device components described above may be combined with one 
or more other components. Moreover, additional components may be provided to perform other 
functions or to assist in performing functions described above. While the components of the user 
device are preferably primarily software-based, one or more components may include hardware 
or firmware aspects. 
20 B. Packet-Switched Telephony Server Provider (VTSP) 

Figure 4 is a simplified block diagram illustrating at least a portion of an exemplary 
Packet-switched Telephony Server Provider (PTSP) system 400. PTSP 400 may be similar to or 
substantially the same as the PSTP 206 of the system 200. The PSTP 400 includes a front end 
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402, a call server 404, and a proxy server 406. Other configurations are also possible, such as 
configurations with different numbers of these components, and are intended to be within the 
scope of the present system. In addition, while the components of PSTP 400 are shown as being 
co-located, this is merely for purposes of illustration, and one or more parts of the PSTP 400 may 
be remotely located from other parts. Similarly, the parts-may be combined into one physical 
device. 

1. Front End 

Figure 5 is a simplified block diagram illustrating an exemplary front end 500. Front end 
500 may be similar to or substantially the same as the front end 402 of the PTSP 400. The front 
end 500 preferably includes a call server database 502 and a load balancer 504. The front end 
500 may be used to select a particular call server 506a-c, if more than one call server is available. 
Although three call servers 506a-c are shown in Figure 5, other numbers of call servers may 
alternatively be provided. If only one call server is provided, then load balancing would likely 
provide httle or no performance benefit In some embodiments, it may be possible to eliininate 
much or all of the front end altogether. In addition, the front end 500 is preferably only involved 
when a call request is first received by the PTSP 400 and possibly to maintain the call server 
database 502. After any interactions the user device 202 has with the front end 500 have been 
completed, many or all user interactions will be primarily through a call server, such as one of 

the call servers 506a-c. 

The front end 500 may be used as call requests are received by the PTSP 400, to assist in 
handling a large number of calls. The PTSP 400 may keep information pertaining to current 
calls in the call server database 502. As a result, the current number of calls on any particular 
server, such as any one of the call servers 506a-c, may be monitored and used to beneficially 



12 




handle new call initiations. The front end 500 may thus access current call data to select an 
appropriate call server for an incoming call request For example, the front end 500 may use call 
density data to determine which of the call servers 406a-c is the least busy, in order to possibly 
improve call performance. As another option, the front end 400 may use a round-robin selection 

5 scheme, in which the front-end 500 distributes individual call requests to the call servers 506a-c 
in some ordered manner irrespective of call density. Other load balancing techniques may also 
be used, such as utilizing particular call servers to correspond to particular users. 

It may be desirable to implement more than one call server 506a-c at a PSTP 400 for one 
or more of the following reasons. The quantity of calls that may be handled by a PTSP 400 will 

10 likely be increased as the PTSP 404 adds call servers 506a-c. For example, a call server 506a-c 
may be able to handle only a limited number of concurrent calls (e.g. up to 150 calls per server) 
before call quality degrades to a certain threshold service level. In addition, different call servers 
506a-c may be optimized to interlace with different gateways, such as the gateway 208 shown in 
the system 200. Different gateways 208 often utilize network equipment provided by different 

15 equipment manufacturers. The likelihood of compatibility problems may be decreased if a call 
server 506a-c is implemented on a device built by the same manufacturer as the gateway 
manufacturer. As an alternative to hardware-matching, a call server's software or firmware may 
be tweaked to increase compatibility with a particular gateway 208. Software tweaking may 
address problems caused by different manufacturers implementing slightly different "flavors" 

20 (additional/alternative features, etc.) of standard protocols, for example. Another advantage of 
using multiple call servers 506a-c is that different call server / gateway combinations may utilize 
different protocols for telephony services. For example, one call server 506a-c may be dedicated 
to a gateway 208 that implements the H.323 protocol, while another call server 506a-c may be 
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dedicated to a gateway 208 running the Session Initiation Protocol (SIP) or the Media Gateway 
Control Protocol (MGCP). If a particular telephony protocol is updated, only the call servers) 
506a-c implementing that protocol is required to implement the update. 

If load balancing is provided by the PTSP 400, then a variety of implementation 

5 techniques may be used, involving software or hardware; for example. In one embodiment, a 
hardware solution called the BIG-IP Controller, available from F5 Networks Inc. of Seattle, 
Washington, may be utilized. In another embodiment, a software solution called Resonate 
Central Dispatch, available from Resonate, Inc. of Sunnyvale, California. Other load balancing 
techniques are known, many of which may be used to advantage in PTSPs 400 handling large 

10 call volumes. Further details regarding the load balancer 504 and the front end 500 may be 
found throughout the specification. 

2. Call Server 

Figure 6 is a simplified block diagram illustrating an exemplary call server 600. Call 
server 600 may be similar to or substantially the same as the call server 404 of the PTSP 400. 
15 The call server 600 preferably includes a call director 602, a plurality of call handlers 604a-c, 
and a call logger 606. Although three call handlers 604a-c are shown in Figure 6, this is merely 
for purposes of illustration, and other quantities ef call handlers may be provided. In one 
alternative embodiment, only one call handler 604 is provided. 

a. Call Director 

20 Figure 7 is a simplified block diagram illustrating an exemplary call director 700, which 

may be included within the call server 600. The call director 700 preferably includes a rules 
database 702 and a branding unit 704. 
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Upon receiving a call request from a user device, such as the user device 202 in the 
system 200, the call director 700 launches a call handler, such as one of the call handlers 604a-c 
shown in Figure 6, if the user device is authorized to make the requested call. The call director 
700 may, for example, access the rules database 702 to determine an authorization status for the 
5 requested call. In an exemplary embodiment, the call director 700 parses a phone number and 
checks the rules database 702 to see if calls are allowed to the destination signified by the prefix 
of the phone number. The rules database 702 may also contain information on service 
agreements with users, so that the call director 700 may determine whether the user device has 
used up a maximum number of minutes, for example. Other authorization techniques may be 
10 implemented in addition to what has been described above, by appropriately modifying the 
information stored in the rules database 702 and/or the operations on the information contained 
in the rules database 702. If the call director 700 determines that the user device 202 is not 
authorized to make a particular call, then an "unauthorized" message may be transmitted to the 
user device 202, or some other action may be taken. Authorization may be determined from a 
1 5 user name / password login process, from an inspection of "cookies" located on the user device 
202, or from some other technique. If the call director 700 determines that the user device 202 is 
authorized to make a particular call, then a call handler 604a-c may be launched, such as through 
the issuance of a launch command (e.g. a UNIX command). 

The branding unit 704 may be included to provide branding information to the user 
20 device. For example, the branding unit 704 may transmit an audio sample to the user device to 
inform the user of the PTSP's 400 identity. Alternatively, advertisements for the PTSP 400 or 
for other commercial entities may be transmitted to the user device 202, such as in a scheme in 
which the user agrees to view advertisements in exchange for receiving telephony service. The 
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selection of which advertisements are transmitted may be based on the phone number to be 
called, the user device 202, the time of day, or other parameters. Other advantages may also be 
realized through various embodiments. Additionally, branding may be performed at a different 
location in the PTSP, or it may be omitted altogether. 
5 b. Call Handler 

Figure 8 is a simplified block diagram illustrating an exemplary call handler 800. The 
call handler 800 preferably includes a call master 802 and a call slave 804. The call master 802 
is linked, such as through a packet-switched network, to a call client 810 on a user device 806. 
The call slave 804 is linked to a gateway 808 through a network, such as a packet-switched 
1 0 network (e.g., the Internet, or a dedicated connection). 

In a multiple-user environment, a call handler similar to the call handler 800 may be 
launched for every call. Thus, in any one call server 600, there may be many calls at any 
particular time. Each call handler 800 may be launched on a specific port that is assigned to the 
user device 806 that initiated the call. Call handlers 800 may communicate with each other, for 
1 5 example, during multiparty conference calls. 

The call master 802 is configured to communicate with the call client 810 on the user 
device 806. The user device 806 and the call master 802 preferably communicate according to a 
non-native protocol having very little overhead and providing specialized information to the 
PTSP 400, such as call quality, etc. Other communications, include pings, Transmission Control 
20 Protocol (TCP) requests, and branding tones, may also be exchanged, according to exemplary 
embodiments. Through the use of such a non-native protocol, the PTSP need not modify the call 
client 810 every time a modification is made to a native telephony protocol. An example of a 
non-native protocol is a proprietary protocol that carries voice data and little else. In contrast, a 
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native protocol (such as H.323, SIP, or MGCP) will typically include overhead to satisfy the 
expectations and requirements defined in the native protocol. Efficiency and robustness may be 
realized by using a streamlined non-native protocol between the user device 806 and the call 
master 802. In addition, the same non-native protocol may be used regardless of what protocol 
5 (e.g. H.323, SIP, MGCP, etc.) is used by the gateway 808. The call client 810 is therefore 
allowed to be small in size (e.g. around 200 kilobytes), relative to existing telephony clients that 
implement much or all of a standard telephony protocol used on a gateway 808. Further details 
regarding the call client 810 and the non-native protocol may be found throughout the 
specification. 

1 0 According to a preferred embodiment, the non-native protocol includes a set of data 

messages in a proprietary format to control basic call functionality. These messages are 
formatted as UDP (User Datagram Protocol), TCP (Transmission Control Protocol), or HTTP 
(Hyper-Text Transport Protocol) and are sent from the user device 806 to the PTSP to properly 
set up, monitor, and tear down calls. The messages in the non-native protocol may include 

15 information such as one or more of the following: an IP address of the user device; a port 
number to transmit data to the user device; an ITU E.164 telephone number, a user name for 
identification; a token, key, and/or password for authorization; and commands for the call 
handler. The messages in the native protocol may include data transferred as Packed Encoding 
Rules (PER), Basic Encoding Rules (BER), or ASN.l notation for H.323 formatted messages, or 

20 Uniform Resource Locator (URL) for SIP formatted messages. Other non-native and native 
protocols may also be used. 

The call slave 804 communicates with the gateway 808 using the native protocol of the 
gateway 808. As a result, the call slave 804 preferably implements a large portion of the native 
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protocol stack, and, in some embodiments, may implement the entire native protocol stack. This 
is in contrast to the call master 802, which need only implement a skeleton non-native protocol. 
When updates or modifications are made to the native protocol associated with the gateway 808, 
only the call slave 804 is modified, according to a preferred embodiment. The call master 802 

5 preferably provides (through the call handler 800) the calTslave 804 with only the minimum data 
required to initiate, maintain, or teardown the call. This minimum data may be all that is 
required by all native protocols supported by all of a PTSP's call servers. As a result, the same 
call master 802 and call client 810 combination may be used for all call servers regardless of 
what native protocol is used, according to a preferred embodiment The call handler 800 may 

10 include protocol stacks of both the native protocol and the non-native protocol to facilitate the 
transfer of call data from the call master 802 to the call slave 804 in the appropriate format The 
call handler 800 may translate the non-native protocol data received by the call master 802 to the 
native protocol used by the call slave 804 to communicate with the gateway 808, and vice versa. 
Thus, in some embodiments, the call slave 804 may be obtained "off-the-shelf;" without any 

15 other modifications being made to the call handler 800. In another embodiment, the call handler 
800 may include protocol stacks for two or more different native protocols, to allow the call 
slave 804 to interface with more than one gateway, each running a different native protocol. 
Additional details regarding the call handler 800 may be found throughout the specification. 

Figure 9 is a simplified block diagram illustrating user device communications with the 

20 call server in a system 900, according to a preferred embodiment The system 900 includes a 
user device 902, a front end 904, and a call server 906. The call server 906 includes a call 
director 908 and a call handler 910. 
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A request to initiate a call 912 from the user device 902 may be received by the front end 
904, which may select the call server 906. The call director 908 within the call server 906 will 
determine an authorization status for the requested call. If the call director 908 determines that 
the user device 902 is not authorized to make a particular call, then the call director 908 may 
send an "unauthorized" message 914 to the user device 902. If the call director 908 determines 
that the user device 902 is authorized to make a particular call, then the call director 908 will 
launch the call handler 910 within the call server 906. Once the user device 902 is authorized, 
the user device 902 and the call server 906 will transmit and receive messages 916 using the call 
handler 910. 

c. Call Logger 

Figure 10 is a simplified block diagram illustrating an exemplary call logger 1000. The 
call logger 1000 preferably includes a display unit 1002 and a connection database 1004. Other 
configurations, including more or fewer components, are also intended to be within the scope of 
the present system. 

The call logger 1000 may be included in a PSTP system, such as the PTSP system 400, in 
order to keep track of all active calls in a particular call server, such as the call server 600. The 
call logger 1000 may also remove inactive connections, which may occur during a disconnect 
event or a specified idle time event, such as 30 seconds of inactivity. For example, the call 
logger 1000 may track at least any of the following: when a call handler 800 is launched, when a 
call is ringing at a target device 212, when a call is established, and when a call is disconnected 
(hung up by the target device 212 or the user device 202). Any or all of these may be stored in 
the connection database 1004, and may preferably be displayed on the display unit 1002 for 
viewing by an administrator of the PTSP 400. Although the call logger 1000 is shown as part of 
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the call server 600, this is merely a preferred embodiment, and the call logger 1000 may be 
situated at another location at or accessible by the PTSP 400. As another alternative, the call 
logger 1000 may be omitted This is, however, not recommended in a multiple-user setting, due 
to the desirability of tracking calls and equipment usage. In another embodiment the connection 
S database 1 004 is associated with (and may be included with) the call server database S02. 
3. Proxy Server 

Figure 11 is a simplified block diagram illustrating an exemplary proxy server 1100. 
Proxy server 1 100 may be similar to or substantially the same as the proxy server 406 of PTSP 
400. The proxy server 1100 preferably includes a registration database 1102 and a gateway 

10 database 1 104. The proxy server 1 100 may be used to select a gateway 1 106a-c, if more than 
one gateway is provided Gateway selection criterion may include the number of calls the 
gateway 1106a-c is haling, the location of the gateway U06a-c, and the type of telephony 
protocol the gateway 1 106a-c uses. 

The registration database 1 102 stores information pertaining to users and/or user devices 

15 202. In a preferred embodiment, every potential user must first register with the PTSP 400 prior 
to placing any calls over equipment maintained by the PTSP 400. This may assist in billing, 
authentication, fraud control, and marketing intelligence, for example. In some embodiments, 
each registered user is associated with one or more proxy servers 1100, and the association is 
stored in the registration database 1 102. 

20 The gateway database 1104 stores information pertaining to the gateways 1106a-c with 

which the PSTP 400 is associated the gateway administration entity (e.g. Focal 
Communications, Sprint, etc.), how many calls are being handled by each gateway 1 106a-c, and 
other information pertaining to gateways 1 106a-c associated with the PTSP 400. 
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The proxy server 1100 may access the registration database 1102 and the gateway 
database 1 104 to select an appropriate gateway 1 106a-c for a call. The proxy server 1 100 may, 
for example, be a gatekeeper according to the H.323 protocol. In a preferred embodiment, the 
proxy server 1 100 is only involved during a gateway selection process. In another embodiment, 

5 only one gateway is present, and the proxy server may be omitted. (In such a case, it may be 
desirable to continue maintaining the registration database 1102 and/or the gateway database 
1104, for system monitoring). After the proxy server 1100 has selected an appropriate gateway 
1106a-c, the IP address of the selected gateway 1106a-c is available to various components 
within the PTSP 400, such as the call handler 800. Although three gateways 1 106a-c are shown 

10 in Figure 1 1, this is for illustrative purposes only, and other numbers of gateways may also be 
provided. 

In a preferred embodiment, the PTSP 400 has a plurality of proxy servers 1 100 associated 
with a respective plurality of gateways 1 106a-c. The proxy server 1 100 used for a particular call 
might, for example, be based on a prefix in a phone number to be called. Other proxy selection 
15 criteria may also be used. 

C. Gateway 

The gateway 208 is a known device that is often located on the premises of a 
conventional (circuit-switched) telephony ^provider. The gateway 208 typically serves at the 
point where data on a call is translated from packet-switched data to circuit-switched data. In 
20 some embodiments, the Public Switched Telephone Network (PSTN) 210 may include packet- 
switching network portions. For purposes of the present system, the details regarding the 
gateway 208 are important primarily for determining what native protocol(s) and networking 
equipment are in use, in order to select an appropriate call server 600 (and call slave 804). 
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D. Target Device 

The target device 212 is preferably a telephone having a direct or indirect connection to 
the PSTN 210, or to some other network. Alternative implementations of the target device 212, 
such as a mobile phone and other communication device, are also intended to be within the scope 

5 of the present system. The details regarding the target device 212 are not of particular 
importance for operation of the PTSP 400. The exact configuration of the target device 212 will 
likely depend on the network(s) between the gateway 208 and the target device 212. The user 
device 202 (or an associated user) need only know how to reach the target device 212, such as by 
dialing a phone number, selecting an address book entry, or entering some other target identifier. 

10 Figure 12 illustrates a packet-switched telephony system 1200, according to a preferred 

embodiment The system 1200 is shown to include components as described above, with like 
reference numerals indicating like functionalities and connections. As was described above, 
many variations may be made from the illustrated configuration, without departing from the 
intended scope of the system. It should also be noted that a target device and a PSTN have been 

1 5 omitted from Figure 1 2 to improve clarity of illustration. 

m. Communication of Packet-Switched Data from the User Device 
A. Call Operation: First Exem plary Embodiment 

Figure 13 is a simplified block diagram illustrating call operation in a telephony system 
1300 according to a first exemplary embodiment The system 1300 includes a user device 1302, 
20 a PTSP 1306, a gateway 1308, and a target device 1312. The user device 1302, the PTSP 1306, 
the gateway 1308, and the target device 1312 of system 1300 may be similar to or substantially 
the same as the user device 202, the PTSP 206, the gateway 208, and the target device 212 of 
system 200. 
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The user device 1302 is linked to both the PTSP 1306 and the gateway 1308 through a 
packet-switched network 1304, such as the Internet The PTSP 1306 is also linked to the 
gateway 1308, such as through the Internet, a dedicated connection, or some other network. The 
gateway 1308 is linked to the target device 1312 through a PSTN 1310 and/or another network. 

The user device 1302 sends call control data via the packet-switched network 1304a to 
the PTSP 1306. Examples of call control data include setup information (e.g. the call request, 
the phone number to call, etc.), ping information sent periodically (e.g. "stay alive" signals, 
signal strength indicators, etc.), and disconnect signals. The user device 1302 sends media data 
via the packet switched network 1304b to the gateway 1308. Thus, if the packet-switched 
network 1304a,b is an IP network, different packets from the user device 1302 may have 
different destination IP addresses, depending on the type of data contained in the packet 

The embodiment shown in Figure 13 may provide performance benefits. Because media 
is transmitted directly to the gateway 1308, rather than through the PTSP 1306, there will likely 
be fewer "hops" between the user device and the target device, resulting in less delay. In 
addition, because an industry standard may be used to communicate media with the gateway, 
there will likely be fewer dropped calls, quicker ping times, and more scalability. One possible 
disadvantage may result from having to implement portions of a native protocol at the user 
device 1302. The call client 1314 may be a. larger download for the user device 1302 than if all 
packets (including media) were transmitted by the user device 1302 to the PTSP 1306, in which 
a non-native protocol could be used for all packet transmissions. Because call control is still 
primarily handled by the PTSP 1306 in the system 1300, the call client 1314 on the user device 
1302 is still likely to be smaller than it would be if call control were implemented at the gateway 
1308. If call control were implemented at the gateway 1308, the user device 1302 would likely 
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need to implement a more complete telephony stack in order to communicate with the gateway 
1308. 

Either party to the call shown in the system 1300 may initiate a disconnect procedure. If 
the target device 1312 initiates the disconnect procedure, the PSTN 1310 forwards the disconnect 
5 request to the gateway 1308. The gateway 1308 communicates the disconnect information to the 
call server of the PTSP 1306, and the call server 600 transmits a disconnect message to the user 
device 1302, to cause the user device 1302 to stop audio traffic transmission and return to a 
"ready" state. If the user device 1302 initiates the disconnect procedure, the call client 1314 on 
the user device 1302 transmits a disconnect message to the call server 600 of the PTSP 1306. 
10 The PTSP 1306 communicates the disconnect request to the gateway 1308 to cause the call to be 
disconnected 

B. Call Operation: Second Exemplary Embodiment 

Figure 14 is a simplified block diagram illustrating call operation in a telephony system 
1400 according to a second exemplary embodiment System 1400 includes a user device 1402, a 

IS PTSP 1406, a gateway 1408, and a target device 1412. The user device 1402, the PTSP 1406, 
the gateway 1408, and the target device 1412 of system 1400 may be similar to or substantially 
the same as the user device 202, the PTSP 206, the gateway 208, and the target device 212 of 
system 200. The user device 1402 is linked to the PTSP 1406 through a packet-switched 
network 1404, such as the Internet The PTSP 1406 is linked to the gateway 1408 through a 

20 packet-switched network, such as the Internet, or some other network. The gateway 1408 is 
linked to the target device 1412 through the PSTN 1410. 

In contrast to the first embodiment shown in Figure 13, packets containing media and call 
control information are transmitted to the PTSP 1406, preferably according to a non-native 
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protocol. The PTSP 1406 (i.e. the call handler 800) transmits the information to the gateway 
1408, according to the native protocol of the gateway 1408. Similarly, media and call control 
packets from the gateway 1408 are transmitted to the PTSP 1410, and the PTSP 1410 transmits 
similar packets to the user device 1402. 

In a potentially advantageous aspect of the second embodiment, the non-native protocol 
includes transmitting the media and/or the call control information as HTTP packets, to assist in 
traversing firewalls, which often block media traffic on unrecognized ports. If a port number 
normally associated a non-telephony application is used (e.g. ports 20, 21, 22, 23, 25, 80, 110, 
119, 443, and/or 7070) is used, then a firewall is more likely to allow the media to pass through. 

In another aspect of the second embodiment, conference calling may be enabled, since all 
media flows through the PTSP 1406. The PTSP 1406 may thus serve as a mixing entity for two 
or more user devices 1402 and/or target devices 1412. 

Figure IS is a message flow diagram illustrating a method 1500 for providing packet- 
switched telephony service, according to an exemplary embodiment. The entities shown as 
transmitting and receiving messages include a user device 1502, a front end 1504, a call server 
1506, a proxy server 1508, and a gateway 1510. Various messages to be set forth below may be 
transmitted or received by entities other man what is described. For example, the front end 1504, 
the call server 1506, and the proxy server 1508 may have lower level components or may be 
included within higher level components, some of which may be involved in the transmission of 
messages, according to alternative embodiments. 

The user device 1502 transmits a call request 1512 to the front end 1504. The call 
request 1512 may include a phone number and a user identification code, for example, 
transmitted via a TCP/IP connection. ("TCP/TP" refers to Transmission Control Protocol / 
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Internet Protocol. TCP is described in J. Postel, ed. "Transmission Control Protocol," IETF RFC 

793, and IP is described in J. Postel, ed, "Internet Protocol," IETF RFC 791, Sept 1981, both of 

which are incorporated by reference herein.) 

The front end 1504 makes a call server selection 1514. In the method 1500, the front end 
5 1504 has selected the call server 1506. 

The call server 1506 determines whether the call request 1512 from the user device 1502 

is valid, which may include determining whether the user identification code and/or the phone 

number to be dialed are authorized under the user's call plan. If the call request 1512 is not 

valid, then the call server 1506 may transmit a rejection message 1516 to the user device 1502. 
10 If the call request 1512 is valid, then the call server 1506 registers the user device 1502 with the 

proxy server 1508, as shown in 1518. 

The proxy server 1508 makes a gateway selection 1520, and transmits a network address 

(e.g. an IP address) to the call server 1506, as shown in 1522. In the method 1500, the proxy 

server 1508 has selected the gateway 1512. 
1 5 The call server 1 506 transmits branding information and an appropriate IP address (which 

may depend upon which embodiment is implemented) to the user device 1502, as shown in 

1524. 

The call server 1506 transmits call setup information 1526 to the gateway 1510 to initiate 
the call, and the gateway 1510 may transmit a call acceptance message 1528 back to the call 
20 server 1506. 

The call server 1506 may transmit a call status indicator 1530 to the user device 1502, 
and a call notification 1532 may be issued from the gateway 1510 to the user device 1502, 
depending on the particular embodiment implemented. A call 1534 is established. Media for the 
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call is preferably transmitted as RTP (Real-time Transport Protocol) over UDP (User Datagram 
Protocol). RTP is described in Schulzrinne et al., "RTP: A Transport Protocol for Real-Time 
Applications," IETF RFC 1889, Jan. 1996, and UDP is described in Postel, "User Datagram 
Protocol," RFC 768, Aug. 1980, both of which are incorporated by reference herein. 

While the call 1534 is in process, the call server 1506 may be in communication 1536 
with the gateway 1510 to monitor the call 1534. The call monitoring may include periodic pings, 
call quality, and error detection, and is preferably conducted using the native protocol of the 
gateway 1510. 

As was discussed above, a disconnect 1538 may be initiated by either party. 

Figure 16 is a simplified block diagram showing an exemplary system 1600 allocating 
assets to a particular telephony protocol. Although the SIP and H.323 protocols are illustrated in 
Figure 16, other numbers and types of protocols may alternatively be employed. The system 
1600 includes a user device 1602, assets assigned to the SIP protocol 1604, assets assigned to the 
H.323 protocol 1606, a PSTN 1608, and a target device 1610. The user device 1602 includes a 
call client 1612. The assets assigned to the SIP protocol 1604 include a SIP call server 1614, a 
SIP proxy server 1616, and a SIP gateway 1618. The assets assigned to the H.323 protocol 1606 
include an H.323 call server 1620, an H.323 proxy server 1622, and an H.323 gateway 1624. 

The user device 1602 may communicate to the assets assigned to a particular protocol 
based on the prefix in a phone number to be called. Other selection criteria may also be 
employed. If a particular telephony protocol is updated, only the call servers) implementing that 
protocol is required to implement the update. 

Figure 17 is a flow diagram illustrating a method 1700 for providing packet-switched 
telephony service, according to an exemplary embodiment The method 1700 includes receiving 
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a call request from a user device 202, as shown in 1 702. The call request includes a target 
indicator of a target device 212 that the user device 202 is attempting to call. For example, the 
target indicator may include a telephone number corresponding to the target device 212. The call 
request received from the user device 202 is formatted and/or received according to a non-native 
5 protocol. In 1 704, a call server 600 is selected to process the call request The call server 600 
may include a call director 700 operable to determine whether the call request is authorized. In 
1706, a call handler 800 is launched upon determining that the call request is authorized. The 
call handler 800 may include a call master 802 and a call slave 804, as described above. The call 
master 802 receives the call request in the non-native protocol, and the call handler 800 converts 

1 0 the call request to a native protocol. In 1 708, the call request is transmitted in the native protocol 
to a gateway 208. The gateway 208 implements the native protocol, and is operable to forward 
the call request to the target device 212. Other functionality may also be included as part of the 
method 1700. For example, the method 1700 may further include selecting the gateway 208 
from a plurality of gateways based on at least one gateway selection criterion. Similarly, 

1 5 functionality described above with respect to Figures 1-16 may also be implemented. 

Figure 1 8 is a flow diagram illustrating a method 1 800 for providing packet-switched 
telephony service, according to another exemplary embodiment In 1802, a call request is 
received from a user device 202. The call request may include a target identifier, such as a 
telephone number corresponding to a target device 212. The call request is in accordance with a 

20 non-native protocol. In 1 804, a call server 600 is selected to process the call request. The call 
server 600 includes a call director 700 operable to determine whether the call request is 
authorized. In 1806, the user device 202 is registered with a proxy server 1 100 upon determining 
that the call request is authorized. The proxy server 1 100 may include a registration data base 
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1 102, for example, to assist in determining authorization. In 1808, a gateway 208 is selected by 
the proxy server 1 100. The proxy server 1 100 may, for example, periodically obtain a gateway 
status, and may maintain a gateway database 1 104. In 1810, a network address corresponding to 
the selected gateway 208 is sent to the call server 600 by the proxy server 1 100. In 1812, the 

5 user device 202 is sent the network address of the selected gateway 208. This information is 
preferably sent in a non-native protocol. In an alternative embodiment, branding information 
and/or advertising information may also be sent to the user device by the call server 600 at this 
time. In 1 814, the call request is transmitted in a native protocol to the gateway 208, which 
operates according to the native protocol. The gateway 208 is operable to forward the call 

10 request to the target device 212, such as via a Public-Switched Telephone Network (PSTN) 210. 
At 1 8 1 6, the gateway 208 sends the call server 600 an acceptance of the call request, preferably 
in the native protocol. In 1818, the call server 600 sends the user device 202 a call status 
indicator, preferably in the non-native protocol. In 1820, a call is established between the user 
device 202 and the gateway 208. This may include the gateway 208 notifying the user device 

15 202 (such as by notification message) that the call is established. The method 1 800 may include 
additional functionality. For example, the call may be monitored by the call server 600 as in 
1 822. As another example, disconnect service may be provided by detecting a disconnect 
indicator (such as a hang-up by the target device 212 or a similar notification by the user device 
202) and performing an appropriate disconnect action as in 1824. Such a disconnect action may 

20 be performed by the gateway 208 or the PSTN 210 in the case of the target device 212, or by the 
call server 600 in the case of the user device 202. 

Figure 19 is a flow diagram illustrating a method 1900 for providing packet-switched 
telephony service, according to yet another exemplary embodiment In 1902, call control data is 
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sent from a user device 202 to a PTSP 400. The call control data may, for example, include a 
call request, ping information, and/or disconnect request information. The call control data is 
preferably included in at least one packet including a first network address specification, such as 
an IP address corresponding to the PTSP 400. Such call control data may be sent by the PTSP 

5 400 to a gateway 208 according to a protocol that is native* to the gateway 208. In 1 904, the user 
device 202 sends media to a gateway 208, so that the gateway 208 may forward the media to a 
target device 212. The media may include, but is not limited to, voice data. The media is 
preferably sent from the user device 202 to the gateway 208 according to a native protocol, and 
preferably consists of at least one packet including a network address specification such as an IP 

1 0 address corresponding to the gateway 208. 

Figure 20 is a flow diagram illustrating a method 2000 for providing packet-switched 
telephony service, according to still yet another embodiment In 2002, call control data and 
media are sent from a user device 202 to a PTSP 400 according to a non-native protocol. In 
2004, the call control data and media are sent from the PTSP 400 to the gateway 208 according 

15 to a native protocol supported by the gateway 208. The gateway 208 may be further operable to 
forward the media to a target device 212. Much of the functionality described with reference to 
Figures 17-19 may also be included in the method 2000. In addition, functionality described 
with reference to Figures 1-16 may also be implemented. 

In view of the wide variety of embodiments to which the principles of the invention can 

20 be applied, it should be understood that the illustrated embodiments are exemplary only, and 
should not be taken as limiting the scope of the present invention. For example, more or fewer 
elements or components may be used in the block diagrams. In addition, the present invention 
can be practiced with hardware or a combination of software and hardware. 
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WE CLAIM: 

1 . A system for providing telephony service over a packet-based network, comprising in 
combination: 

a call director operable to receive a call request over a packet-based network and 
to determine whether the call request is authorized; and 

a call handler operable to translate the call request from a non-native protocol to a 
native protocol, wherein the native protocol is associated with a gateway to a circuit- 
switched network. 

2. The system of Claim 1, further comprising a call logger operable to track calls. 

3. The system of Claim 1, wherein the call director launches the call handler upon 
determining that the call request is authorized 

4. The system of Claim 1 , wherein the non-native protocol includes a set of data messages 
in a proprietary format to control call functionality. 

5. The system of Claim 4, wherein the set of data messages is formatted according to a 
protocol selected from the group consisting ofUDP, TCP, and HTTP. 

6. The system of Claim 4, wherein the set of data messages includes information selected from 
the group consisting of an IP address, a port number, an ITU E.164 phone number, a user name, 
a token, a key, a password, and a command for the call handler. 
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7. The system of Claim 4, wherein the native protocol includes at least one protocol selected 
from the group consisting ofH.323, Session Initiation Protocol, and Media Gateway Control 
Protocol. 

8. The system of Claim 1, wherein the call handler includes protocol stacks for both the 
non-native protocol and the native protocol. 

9. The system of Claim 1, wherein the call handler comprises a call master and a call slave. 

10. A system for providing telephony service to a user device, wherein the user device is 
linked to a packet-based network, comprising in combination: 

a user device interface operable to accept information from a user pertaining to a 
call request; and 

a call client application operable to formulate the call request according to a non- 
native protocol 

1 1 . The system of Claim 10, wherein the non-native protocol includes a set of data messages 
in a proprietary format to control call functionality. 

12. The system of Claim 11, wherein the set of data messages is formatted according to a 
protocol selected from the group consisting ofUDP, TCP, and HTTP. 
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13. The system of Claim 1 1, wherein the set of data messages includes information selected 
from the group consisting of an IP address, a port number, an ITU E.164 phone number, a user 
name, a token, a key, a password, and a command for the call handler. 

14. A system for providing telephony service over a packet-based network, comprising in 
combination: 

a front-end server operable to receive a call request from a user device, wherein 
the user device communicates the call request according to a non-native protocol; 

at least one call server operable to initiate a call according to the call request; and 
at least one proxy server operable to select a gateway to a public switched 
telephone network, wherein the gateway operates according to a native protocol. 

1 5 . The system of Claim 14, wherein the front-end server comprises a load balancer operable 
to select a target call server from the at least one call server. 

16. The system of Claim 15, wherein the front-end server further comprises a call server 
database including information pertaining to the at least one call server. 

17. The system of Claim 14, wherein each of the at least one call server comprises a call 
director, wherein the call director is operable to determine whether the call request is valid, and 
wherein the call director is additionally operable to launch a call handler upon determining that 
the call request is valid. 
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18. The system of Claim 14, wherein each of the at least one call server comprises: 
a call director operable to determine whether the call request is valid; and 
a call handler, wherein the call handler is operable to receive packets from the 
user device in the non-native protocol, and wherein the caU handler is additionally 
operable to transmit packets to the gateway in the native protocol. 



19. The system 
native protocol. 

20. The system 
MGCP. 



of Claim 18, wherein the non-native protocol is composed of a subset of the 



of Claim 19, wherein the native protocol is selected from H.323, SIP, and 



21. The system of Claim 14, wherein the proxy server selects the gateway by accessing at 
least one of a registration database and a gateway database. 

22. The system of Claim 14, wherein the front-end server comprises a load balancer operable 
to select a target call server from the at least one call server, wherein the proxy server selects the 
gateway by accessing a regist^ 

least one call server comprises: 

a call director operable to determine whether the call request is valid; and 
a call handler, wherein the call handler is operable to receive packets from the 
user device in the non-native protocol, and wherein the call handler is additionally 
operable to transmit packets to the gateway in the native protocol. 
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23 . The system of Claim 22, wherein the registration database and the gateway database are 
included within a single database. 

24. The system of Claim 23, wherein the native protocbl is selected from H.323, SIP, and 
MGCP. 

25. The system of Claim 22, wherein each of the at least one call server further comprises a 
call logger. 

26. The system of Claim 14, wherein the front-end server comprises a load balancer operable 
to select a target call server from the at least one call server, and wherein each of the at least one 
call server comprises a call director, a call handler, and a call logger. 

27. A system for providing telephony service, comprising in combination: 

a call client downloadable to a user device located on a packet-switched network, 
wherein the call client is operable to transmit a first call request according to a non-native 
protocol; and 

a call server located on the packet-switched network, wherein the call server is 
operable to receive the first call request according to the non-native protocol, wherein the 
call server is operable to transmit a second call request according to a native protocol. 
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28. The system of Claim 27, Anther comprising a gateway operable to receive the second call 
request according to the native protocol, and wherein the gateway is operable to initiate a call on 
a circuit-switched network. 

29. The system of Claim 27, further comprising a front-end server operable to receive a call 
request from the user device. 

30. The system of Claim 29, wherein the front-end server comprises a load balancer operable 
to select the call server from a plurality of call servers. 

31. The system of Claim 27, further comprising a proxy server operable to select the gateway 
from a plurality of gateways. 

32. A method for providing packet-switched telephony service, comprising in combination: 

receiving a call request from a user device, wherein the call request includes a 
target indicator corresponding to a target device, and wherein the call request is in 
accordance with a non-native protocol; 

selecting a call server to process the call request, wherein the call server includes 
a call director operable to determine whether the call request is authorized; 

launching a call handler includes a call master and a call slave, wherein the call 
master receives the call request in the non-native protocol, wherein the call handler 
converts the call request to a native protocol; 
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transmitting the call request in the native protocol to a gateway, wherein the 
gateway implements the native protocol, and wherein the gateway is operable to forward 
the call request to the target device. 

33. The method of Claim 32, further comprising selecting the gateway from a plurality of 
gateways based on at least one gateway selection criterion. 

34. The method of Claim 33, wherein the at least one gateway selection criterion includes at 
least one criterion selected from the group consisting of number of calls, location of gateway, 
and type of telephony protocol. 

35. The method of Claim 32, wherein the user device makes a call request on a web site 
associated with the call server. 

36. The method of Claim 35, wherein the web site can be accessed using a web-browser. 

37. The method of Claim 32, wherein the target indicator is a phone number, wherein the 
target device is associated with a target phone number, and wherein the web site is operable to 
receive the target phone number. 

38. The method of Claim 32, wherein the web site is operable to select an address book 
selection to obtain the target indicator. 
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39. The method of Claim 32, wherein the gateway forwards the call request to the target 
device through a public switched telephone network. 

40. The method of Claim 32, wherein the call request consists of at least one packet 

41 . The method of Claim 32, wherein the user device is operable to access the Internet. 

42. The method of Claim 32, wherein the user device is operable to execute a telephony 
client. 

43. The method of Claim 32, wherein the user device is a device selected from the group 
consisting of a personal computer, a mobile phone, a wireless handheld, and a packet-switched 
telephone. 

44. The method of Claim 32, wherein the user device includes a call client 

45. The method of Claim 44, wherein the call client includes a software library and a virtual 
machine. 

46. The method of Claim 45, wherein the virtual machine is a Java virtual machine. 
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47. The method of Claim 45, wherein the software library includes at least one component 
selected from the group consisting of an application program interface, a voice codec, and a call 
control stack. 

48. The method of Claim 45, wherein the virtual machine includes a graphical user interface. 

49. The method of Claim 32, wherein the call server further comprises a plurality of call 
handlers and a call logger. 

50. The method of Claim 49, wherein the call logger includes a display unit and a connection 
database. 

51. The method of Claim 49, wherein the call logger tracks active calls. 

52. The method of Claim 49, wherein the call logger removes inactive calls from a database. 

53. The method of Claim 49, wherein the call logger tracks at least one event selected from 
the group consisting of a call handler launch, a call ringing at the target device, an establishment 
of a call, and a disconnection of a call. 

54. The method of Claim 32, wherein the call director includes a rules database and a 
branding unit. 
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55. The method of Claim 54, wherein call director accesses the rules database to determine if 
the call request is authorized. 

56. The method of Claim 54, wherein the call director is operative to send a message to the 
user device if the call request is not authorized 

57. The method of Claim 54, wherein the branding unit provides branding information to the 
user device. 

58. The method of Claim 32, wherein the call handler is launched for every call. 

59. The method of Claim 32, wherein the non-native protocol includes a set of data messages 
in a proprietary format to control call functionality. 

60. The method of Claim 59, wherein the set of data messages is formatted according to a 
protocol selected from the group consisting ofUDP, TCP, and HTTP. 

6 1 . The method of Claim 59, wherein the set of data messages includes information selected 
from the group consisting of an IP address, a port number, an ITU E.164 phone number, a user 
name, a token, a key, a password, and a command for the call handler. 
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62. The method of Claim 32, wherein the native protocol includes at least one protocol 
selected from the group consisting of H.323, Session Initiation Protocol, and Media Gateway 
Control Protocol. 

63. The method of Claim 32, wherein the call handler includes protocol stacks for both the 
non-native and the native protocols. 

64. The method of Claim 32, further comprising selecting the gateway. 

65. The method of Claim 64, wherein the gateway is selected by a proxy server, and wherein 
the proxy server is operable to access a registration database and a gateway database. 

66. The method of Claim 65, wherein the registration database stores information pertaining 
to at least one user device. 

67. The method of Claim 65, wherein the gateway database stores information pertaining to 
at least one gateway. 

68. The method of Claim 32, wherein the target device is a telephone having a connection to 
a public switched telephone network. 

69 A method for providing packet-switched telephony service, comprising in combination: 
receiving a call request from a user device according to a non-native protocol; 
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providing a call server to process the call request, wherein the call server includes 
a call director operable to determine whether the call request is authorized; 

registering the user device with a proxy server upon determining that the call 
request is authorized, wherein the proxy server is operable to periodically obtain a 
gateway status; 

selecting a gateway based on the gateway status, wherein the gateway operates 
according to a native protocol; 

transmitting a network address to the user device in a non-native protocol, 
wherein the network address is associated with the gateway; 

transmitting the call request to the gateway in the native protocol, wherein the 
gateway implements the native protocol, and wherein the gateway is operable to forward 
the call request to the target device; 

transmitting a call status indicator to the user device; and 

establishing a call. 

70. The method of Claim 69, wherein the call request includes a telephone number 
corresponding to the target device. 

71 . The method of Claim 69, wherein the call director transmits an unauthorized message to 
the user device if the call request is not authorized. 

72. The method of Claim 69, wherein the proxy server is operable to access a registration 
database and a gateway database. 
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73. The method of Claim 69, further comprising transmitting branding information from the 
call server to the user device. 

74. The method of Claim 69, wherein the gateway notifies the user device that the call is 
established 

75. The method of Claim 69, wherein the call server monitors the call. 

76. The method of Claim 69, wherein either the user device or the target device can 
disconnect the call. 

77. A method for providing packet-switched telephony service, comprising in combination: 

sending call control data from a user device to a packet-switched telephony 
service provider according to a non-native protocol; and 

sending media from the user device to a gateway according to a native protocol. 

78. The method of Claim 77, wherein the call control data includes data selected from the 
group consisting of a call request, ping information, and disconnect signals. 

79. The method of Claim 77, further comprising sending call control data from the packet- 
switched telephony service provider to the gateway according to the native protocol. 
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80. The method of Claim 77, wherein the media includes voice data. 

81. The method of Claim 77, wherein the gateway is operable to forward the media to a 
target device. 

82. The method of Claim 77, wherein the call control data is included in at least one packet 
having a first network address specification. 

83. The method of Claim 82, wherein the first network address specification is an IP address 
corresponding to the packet-switched telephony service provider. 

84. The method of Claim 77, wherein the media is included in at least one packet having a 
second network address specification. 

85. The method of Claim 84, wherein the second network address specification is an IP 
address corresponding to the gateway. 

86. A method for providing packet-switched telephony service, comprising in combination: 

sending call control data and media from a user device to a packet-switched 
telephony service provider according to a non-native protocol; and 

sending the call control data and the media from the packet-switched telephony 
5 service provider to a gateway according to a native protocol. 
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87. The method of Claim 86, wherein the call control data includes data selected from the 
group consisting of a call request, ping information, and disconnect signals. 

88. The method of Claim 86, wherein the media includes voice data. 

89. The method of Claim 86, wherein the gateway is operable to forward the media to a 
target device. 

c 

90. The method of Claim 86, wherein the call control data and media are included in at least 
one packet having a first network address specification. 

9 1 . The method of Claim 90, wherein for call control data and media sent from the user 
device to the packet-switched telephony service provider the first network address specification 
is an IP address corresponding to the packet-switched telephony service provider. 
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ABSTRACT 

A system and method for providing packet-switched telephony service. The system 
provides call control, signaling, and/or delivery of voice, video, and other media in substantially 
real time. One embodiment of the system includes a call client application on a user device, and 
a call server located at a packet-switched telephony service provider. The call server is 
preferably operable to communicate with the call client in a non-native protocol and with the 
gateway in a native protocol 
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In consideration of One Dollar (SI. 00) and other good and valuable considerations in hand paid, the 
receipt and sufficiency whereof are hereby acknowledged, the undersigned hereby assign to: 



its successors and assigns, the entire right, title and interest in the invention or improvements of the undersigned 
disclosed in an application for Letters Patent of the United States, entitled: 



in the offices of McDonnell Boehnen Hulbert & Berghoff and in said application and any and all other 
applications, both United States and foreign, which the undersigned may file, either solely or jointly with others, 
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assigns to said assignee the priority right provided by the International Convention. 
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of the application. 

The undersigned warrant themselves to be the owners of the entire right, title and interest in said 
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outstanding prior assignments, licenses, or other encumbrances on the interest herein assigned. 

For said considerations the undersigned hereby agree, upon the request and at the expense of said 
assignee, its successors and assigns, to execute any and all divisional, continuation and substitute applications for 
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application for the reissue or extension of any Letters Patent that may be granted upon said application and any 
and all applications and other documents for Letters Patent in foreign countries on said invention or 
improvements, that said assignee, its successors or assigns may deem necessary or expedient, and for the said 
considerations the undersigned authorize said assignee to apply for patents for said invention or improvements in 
its own name in such countries where such procedure is proper and further agree, upon the request of said 
assignee, its successors and assigns, to cooperate to the best of the ability of the undersigned with said assignee, 
its successors and assigns, in any proceedings or transactions involving such applications or patents, including the 
preparation and execution of preliminary statements, giving and producing evidence, and performing any and all 
other acts necessary to obtain, maintain and enforce said Letters Patent, both United States and foreign, and vest 
all rights therein hereby conveyed in the assignee, its successors and assigns, whereby said Letters Patent will be 
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held and enjoyed by the said assignee, its successors and assigns, to the full end of the term for which said Letters 
Patent will be granted, as fully and entirely as the same would have been held and enjoyed by the undersigned if 
this assignment had not been made. 
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